Sifrovani dat v IB/FB
Otázka od: Martin Burle
1. 12. 2002 22:31
Ahoj,
se zajmem jsem si procetl starsi diskuse o zabezpeceni dat v IB/FB. Nektera
doporuceni mi pripadla jako z jineho sveta 
. Mam dojem, ze aplikace
postavene na IB pobezi predevsim v mensich a strednich podnicich, kde
a) nemaji server nekde pod zamkem, pokud vubec nejaky dedikovany server maji
b) jako OS casto pouzivaji Win9x
c) riziko odcizeni databaze nebo jeji zalohy je realne (tisic prilezitosti),
databaze neni nijak velika
d)presto by v praxi stacilo jednoduche sifrovani dat, defacto znecitelneni
presto maji v db nejaka data, ktera chteji utajit. S IB se teprve seznamuji,
ale pokud tomu dobre rozumim, tak odnesu-li odnekud databazi, dostanu se do
ni na jakemkoli IB serveru. Dokonce, pokud budu chtit napr. zjistit neci
telefonni cislo, staci mi k tomu jakykoli prohlizec. Zajimalo by mne, jake
jsou zkusenosti se sifrovanim dat na IB, jake kdo pouziva metody (nemyslim
ted sifrovaci algoritmy, ale jak je sifrovani implementovano a kde probiha),
jake jsou pro/proti, jake to prinasi problemy atd.
Zkusil nekdo nejaky soft, ktery sifruje data primo na disku?
Neplanuje se (otazka pro Pavla Cisare) implementace sifrovani primo do FB?
Martin Burle
Odpovedá: Pavol Kakacka
2. 12. 2002 8:16
From: "Martin Burle" <mburle2@volny.cz>
> se zajmem jsem si procetl starsi diskuse o zabezpeceni dat v IB/FB.
Nektera
> doporuceni mi pripadla jako z jineho sveta .
Hmm, obecne platna i pre ine DB stroje ;)
> Mam dojem, ze aplikace
> postavene na IB pobezi predevsim v mensich a strednich podnicich, kde
Hmm, co povazujes za stredne podniky ;)
> a) nemaji server nekde pod zamkem, pokud vubec nejaky dedikovany server
maji
> b) jako OS casto pouzivaji Win9x
> c) riziko odcizeni databaze nebo jeji zalohy je realne (tisic
prilezitosti),
> databaze neni nijak velika
Kazdy podnik ma tento problem ak ma aspon jednoho cloveka ktory ma pravo k
DB pristupovat !!!
*1 Okre toho i kazdy uzivatel pracujuci s urcitou agendou ma moznost dostat
sa k urcitym datam !!!
Toto je realne riziko aboslutne kazdej firmy i so sebelepsim zabezpecenim.
> d)presto by v praxi stacilo jednoduche sifrovani dat, defacto znecitelneni
Je to k nicemu viz. *1
> presto maji v db nejaka data, ktera chteji utajit. S IB se teprve
seznamuji,
> ale pokud tomu dobre rozumim, tak odnesu-li odnekud databazi, dostanu se
do
> ni na jakemkoli IB serveru. Dokonce, pokud budu chtit napr. zjistit neci
> telefonni cislo, staci mi k tomu jakykoli prohlizec.
Existuju zabezpecenia ako to nebezpecenstvo eliminovat, ale hacker a nemusi
byt ani prilis dobry, urcite rozluskne kazde zabezpecenie.
> Zajimalo by mne, jake
> jsou zkusenosti se sifrovanim dat na IB, jake kdo pouziva metody (nemyslim
> ted sifrovaci algoritmy, ale jak je sifrovani implementovano a kde
probiha),
> jake jsou pro/proti, jake to prinasi problemy atd.
Jedina vec a nutna v kazdom pripade, je zabezpecit server (PC(s) na ktorom
IB/FB bezi)
> Zkusil nekdo nejaky soft, ktery sifruje data primo na disku?
Pri desiatkach/stovkach konekcii si to z vykonnostnych dovodv nemozes
dovolit.
A nakoniec Ti to i tak bude k nicomu, pretoze ak sa niekto dostane k servru
aj tak si odtial odnesie co chce.
Takze Alfa a Omega problemu je zabezpecit server a doverovat ludom, ktory k
nemu maju pristup ;)
Kakacka Pavol
KasiX@atlas.cz
Odpovedá: Martin Burle
2. 12. 2002 9:53
----- Original Message -----
From: "Pavol Kakacka" <kakacka@proca.cz>
> Hmm, co povazujes za stredne podniky ;)
treba kolem 20 lidi
> > d)presto by v praxi stacilo jednoduche sifrovani dat, defacto
znecitelneni
> Je to k nicemu viz. *1
S tim bych si dovolil nesouhlasit. Podle meho ze stovky lidi, kteri by
chteli db ukrast, nebo se v ni alespon postourat, jich 50 odpadne, protoze
vubec nevedi, kde a co vubec hledat a ze zbytku 99%, jakmile zjisti, ze
data neumi precist. Zpravidla se jedna spise o zlomyslnost, a tito lide
nebudou investovat cas/penize do prolomeni byt jednoduche ochrany. Vubec
jsem nechtel nastartovat diskuzi o neprolomitelnem zabezpeceni.
Kdyz nekomu nabizim aplikaci postavenou na pdoxu, a na dotaz o moznosti
sifrovani reknu: "ano, ale pro odbornika neni problem data otevrit", slycham
"OK, nechceme jen, aby data mohl otevrit kazdy (nas) nouma".
> Takze Alfa a Omega problemu je zabezpecit server a doverovat ludom, ktory
k
> nemu maju pristup ;)
V nasem kraji? 
Martin Burle
Odpovedá: Pavol Kakacka
2. 12. 2002 9:57
From: "Martin Burle" <mburle2@volny.cz>
> > Hmm, co povazujes za stredne podniky ;)
> treba kolem 20 lidi
Aha, tak jak si pod stredne velkym (ked sa nepozrieme na obrat) predstavujem
okolo 50 az 100 ludi
> > > d)presto by v praxi stacilo jednoduche sifrovani dat, defacto
> znecitelneni
> > Je to k nicemu viz. *1
>
> S tim bych si dovolil nesouhlasit. Podle meho ze stovky lidi, kteri by
> chteli db ukrast, nebo se v ni alespon postourat, jich 50 odpadne, protoze
> vubec nevedi, kde a co vubec hledat a ze zbytku 99%, jakmile zjisti, ze
> data neumi precist. Zpravidla se jedna spise o zlomyslnost, a tito lide
> nebudou investovat cas/penize do prolomeni byt jednoduche ochrany. Vubec
> jsem nechtel nastartovat diskuzi o neprolomitelnem zabezpeceni.
> Kdyz nekomu nabizim aplikaci postavenou na pdoxu, a na dotaz o moznosti
> sifrovani reknu: "ano, ale pro odbornika neni problem data otevrit",
slycham
> "OK, nechceme jen, aby data mohl otevrit kazdy (nas) nouma".
Predpokladal som ze tie "stovky lidi z kterych 50 odpadne" sa nedostanu ani
k servru .
V pripade, ze chces mat firemne data na nezabezpecenom PC (ala server) sa to
da zabezpecit tiez,
ale skutocne to musi byt na urovni DB, na nezabezpecenom PC (servru) nic ine
nama zmysel. Metod je viac, moc ich nie je prilis verejnych ale daju sa
dohladat na netu. A ked je to do 20 ludi tak v tom pripade by slo pouzit i
sifrovanie na strane klienta.
Myslim ale ze je treba si polozit otazku, ci su tie firemne data tak cenne
ze ich nebudeme mat na zabezpecenom PC vs. ci je potreba sa zatazovat s
"aspon jaku takou" ochranou.
> > Takze Alfa a Omega problemu je zabezpecit server a doverovat ludom,
ktory
> k nemu maju pristup ;)
> V nasem kraji?
, rozumiem, ale "nemas" inu moznost.
Kakacka Pavol
KasiX@atlas.cz
Odpovedá: Pavel Cisar
2. 12. 2002 9:24
Haj hou!
On 1 Dec 2002 at 22:19, Martin Burle wrote:
> Mam dojem, ze aplikace postavene na IB pobezi predevsim v mensich a
> strednich podnicich, kde
>
> a) nemaji server nekde pod zamkem, pokud vubec nejaky dedikovany server maji
> b) jako OS casto pouzivaji Win9x
To je naprosta pitomost, sorry. Doby kdy firmy o 3 PC nemely dedikovany
server jsou ty tam. Pokud je ve firme Internet, sdileji se soubory,
tiskarny, alespon jedna podnikova aplikace atd. tak si uz kazdy porizuje
dedikovany server. Prijde to na 40 tisic za HW a pokud nechteji
investovat do NT, provozuji Linux se Sambou. Ale do 5 stanic postaci i
predinstalovane W2000 Pro jako server.
> c) riziko odcizeni databaze nebo jeji zalohy je realne (tisic prilezitosti),
> databaze neni nijak velika
Jako vsude. DOBRE zabezpecit IT proti utoku ZEVNITR neni zadna sranda, a
pro male podniky je to temer nemozne s jakymkoliv SW.
> d)presto by v praxi stacilo jednoduche sifrovani dat, defacto znecitelneni
Mytus.
> Zajimalo by mne, jake jsou zkusenosti se sifrovanim dat na IB, jake kdo
> pouziva metody (nemyslim ted sifrovaci algoritmy, ale jak je sifrovani
> implementovano a kde probiha), jake jsou pro/proti, jake to prinasi
> problemy atd.
Sifrovani polozek v databazi komplikuje nebo primo znemoznuje efektivni
vyhledavani dat v databazi. Lide ale stejne musi mit pravo nektera data
videt v citelne podobe, a ta se tim padem daji zcizit, byt treba tiskem
na tiskarne, exportem do Excelu nebo v nejhorsim pripade opisem z
obrazovky.
Sifrovani nadisku je pomale a resi pouze problem zcizeni cele databaze
kopirovanim souboru (ale uz ne backupem nebo jinou regulerni extrakci
dat). Prava filesystemu jsou jednodussi, rychlejsi a maji stejny efekt.
Sifrovani je metoda ochrany proti utoku ZVENCI, nikoliv zevnitr.
> Neplanuje se (otazka pro Pavla Cisare) implementace sifrovani primo do FB?
Ne, je to k nicemu. Planuji se jine metody zlepseni zabezpeceni:
- Restrikce umisteni externich tabulek, funkci, databazi na serveru
- ALIASy pro databaze odstranuji nutnost znat umisteni databaze
- Delsi hesla nez 8 znaku
- Lepsi sifrovani hesel v isc4.gdb
- Svazani isc4.gdb s konkretnim serverem (RSA)
- Svazani databaze s konkretnim serverem (datapage mangling)
- Sifrovani na urovni prenosoveho protokolu, ale to jde i dnes externimi
nastroji
- Metadata security
S pozdravem
Pavel Cisar
Mobil: 724 281429
http://www.ibphoenix.cz
Vse co potrebujete pro Firebird a InterBase
Odpovedá: Petr Fejfar
2. 12. 2002 16:48
From: "Pavel Cisar" <pcisar@users.sourceforge.net>
> > d)presto by v praxi stacilo jednoduche sifrovani dat, defacto
znecitelneni
> Mytus.
Na to je nutne se divat ocima projektanta:
* bezpecny system nevytvoris tj. pro kazdy system bude existovat
nejaka nenulova pravdepodobnost P1, ze bude narusen.
* pokud nasadis "cistou" FB v nejakych konkrektnich podminkach,
pak je P1 samozrejme agregaci mnoha ruzne velkych dilcich
pravdepodobnosti ruznych typu naruseni.
* pokud zasifrujes citliva data v databazi, pak snizis pravdepodobnost
naruseni takoveho systemu na P2
A protoze P2<P1, tak to neni zadny mytus a otazka nestoji, jestli
sifrovat ANO/NE, ale CO a JAK, aby to prineslo v konkrektnich
podminkach ocekavany efekt a veslo se to do rozumnych nakladu.
> Sifrovani polozek v databazi komplikuje nebo primo znemoznuje efektivni
> vyhledavani dat v databazi.
Komplikuje - ale da se to v praxi celkem dobre provozovat
Horsi je, ze aby se udrzela pravdepodobnost naruseni sifrovanych dat
na rozumne mezi (je dana predevsim klicem, protoze algoritmus
je zpravidla obecne znam), je nutne data pravidelne presifrovat
novym klicem. A to uz je komplikace docela znacna
(napr. z duvodu konzistence dat musi vsechno presifrovani
probehnout v jedne transakci, takze nam treba pretekl transakcni log
atd).
> Lide ale stejne musi mit pravo nektera data
> videt v citelne podobe,
Nemusi - ne s kazdou DB operuje primo clovek - a i kdyz ano,
tak ne vsichni lide museji videt vsechna data.
> Sifrovani je metoda ochrany proti utoku ZVENCI, nikoliv zevnitr.
Jak jsi na to prisel? Ono to bude sice zalezet na kontretnich podminkach,
ale typicky se proti utoku ZVENCI sifruji prenosy dat, ne obsahy databazi
- tam se vetsinou dela maximum pro to, aby se ven pokud mozno nedostaly.
My jsme delali napr. system, kde zakaznik pozadoval sifrovani vybranych
polozek v databazi prave proti nekterym tridam vlastnich zamestnancu.
Muj team se nikdy nedostal k ostrym datum - ta byla do systemu
zavedena personalem zakaznika za specialnich bezpecnostnich
opatreni po te, co se system odzkousel ve zkusebnim provozu
a byl predan zakaznikovi. Stejne tak se nikdo z nas od spusteni
ostreho provozu nedostal k serverum.
A pravdepodobnost, ze by se to nekomu z nas povedlo je IMHO
z pohledu zakaznika rozumne mala...
HTH, pf
Odpovedá: Martin Burle
2. 12. 2002 21:57
----- Original Message -----
From: "Petr Fejfar" <development@callnet.cz>
> My jsme delali napr. system, kde zakaznik pozadoval sifrovani vybranych
> polozek v databazi prave proti nekterym tridam vlastnich zamestnancu.
Muzes prosim malinko nastinit vami pouzitou technologii sifrovani (kde,
cim), pripadne nejake prameny?
Diky,
Martin Burle
Odpovedá: Martin Burle
2. 12. 2002 21:50
----- Original Message -----
From: "Pavel Cisar" <pcisar@users.sourceforge.net>
> Planuji se jine metody zlepseni zabezpeceni:
> - Restrikce umisteni externich tabulek, funkci, databazi na serveru
> - ALIASy pro databaze odstranuji nutnost znat umisteni databaze
> - Delsi hesla nez 8 znaku
> - Lepsi sifrovani hesel v isc4.gdb
> - Svazani isc4.gdb s konkretnim serverem (RSA)
> - Svazani databaze s konkretnim serverem (datapage mangling)
To by mohlo dost pomoci. Dnes staci odnest db na jiny server nebo prohodit
isc4.gdb (mam dojem, nezkousel jsem). Ale kdyz uz FB umi sifrovani (hesel -
a bude se dokonce vylepsovat) ....?
Martin Burle
Odpovedá: Petr Fejfar
3. 12. 2002 4:48
From: "Martin Burle" <mburle2@volny.cz>
> Muzes prosim malinko nastinit vami pouzitou technologii sifrovani (kde,
> cim), pripadne nejake prameny?
* Cilova databaze byla IBM DB2, ale vyvoj jsme delali na lokalni IB 6.01
* Jednalo se o bezobsluznou serverovskou aplikaci
* Hot-line a podobne sluzby zakaznika pouzivaly klienty na bazi www
* Z pohledu DB se sifrovalo na strane klienta
* Pro sifrovani byly pouzity symetricke algoritmy schvalene/respektovane
v danem odvetvi
* klice pro sifrovani se odvozovali ze sifrovane ulozenych kryptograficky
silnych message digestu nezavislych hesel
* zasifrovane hodnoty se zakodovaly do Base64 a ukladaly jako retezce
* zadna zasifrovana hodnota nebyla pouzita v klauzuli WHERE
(ale dala by se - hledala by se zasifrovana hodnota argumentu)
* Pri zmene vsech nezavislych hesel se vsechna data v DB automaticky
presifrovala.
* K implementaci jsme pouzili nedavno diskutovane DEC od
Hagena Reddmanna.
Tak heslovite je to tak vsechno.
HTH, pf